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BACKGROUND OF THE INVENTION 
As the credrt card industry has evolved and grown more competitive over the 

distinguish themselves from their competition by introducing new features and 
benefits withtheircredit card, Among these featu.es have been programs that 
^theconsomer for usingtheir credit card vnthrcduc^ interest rates c« the 
pord^ amount, accn^re^tede^ 

red ^ n ^eattteteof P ur C h aS ,. Some of the rrK,te successful reward 



issuers to include inserts with 
services. The targeting 



15 for these inserts is based, however, on 

consumer, abl^^.— c-^^*^^ 1 ^* 

them. 

IT***.—-"- Today Aerc^^^ofv^aval.bfc^te 

newspaper, radio a: 
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Targeted marketing is particularly effective and efficient for merchants 
because U is designed to identify consumers that are more likely than the general 
public to be interested in the merchant's products or services. One proven method has 
been to identify consumers that have demonstrated interest by purchasing similar or 
related products in the part. One vray for merits to obtam^^ 
been to purchase consumer lists from various providers. These lists are again, 
however, generally based on rather limited, static targeting criteria. 

Merchants thus desire a flexible, cost effective method for finding consumers 
who will be interested in their products or services. Consumers on the other hand 
desire discounts on products and services they want or need. Urifortunately, the 
structure of the bank card world (Visa and MasterCard) makes the accomplishing of 
these seemingly parallel goals difficult Cardholder transaction histories, a key to 

and controlled by the cardholders' issuing financial institutions and are unavailable to 
merchants and their acquiring financial institutions who are separated from the 
cardholders and their issuers by the Visa and MasterCard mterchanges, across which 
money, but not information, passes. 

Merchants and their acquirers do not therefore have access to the cardholder 
kfbrmationnec*^ 



AnirKhvioWfirancia^ 

bridgeme gap for rte own merchant 

subset of cardholder is obviously of less value to merchants and the limited range of 
merchant offers is similarly of less value to cardholders and will be less effective in 
stmimating card usage. The divide between merchants and their acquirers and 
cardholders and their issuers can be bridged however by a credit card processor that 
receives information from both sides ofthe interchange and has the processing 
capacity to perform the necessary offer matching, delivery, and fulfillment. 
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SUMMARY OF THE INVENTION 
The purpose of the present invcation is to meet the objectives of merchants 
(which includes service providers) and consumers as well as the financial institutions 
on both sides of the interchange. Specifically, the goal is to provide merchants with a 
flexible, cost effective method to provide a large number of interred consumers with 
value propositions that discount the merchants products and services, and to provide 
consumers, or cardholders, with a broad range of merchant offers in which they will 
be most interested. A further goal and effect of the invention will be to increase the 
use of the bankcards of participating financial institutions, which provides a 
convenient automated means for implementing targeted discounts without the need for 
coupons, mailings, or additional transactions on the part of either the cardholder or 
merchant Finally, the invention meets the above objectives while at the same time 
preserving the consumers' privacy by avoiding the dissemination of the cardholders- 
transaction histories to merchants or outside financial institutions. 

To meet these objectives the invention trtilizes five basic steps: (1) an 
automated process which enables the merchant to target consumers based on purchase 
behavior and geographic location; (2) an automated process which matches targeted 
ra erchantoffea ga ^ 
an autoiraled proems v^*^ 

e consumer to act on 



the value proposition and receive a 
the need of a coupon or additional traductions; (5) an automated process which 
reports on the execution of the discount transaction to the consumer and merchant. 

in the first step, the merchant can, through an automated process, define 
targeting criteria based on consumer historic purchase activity by Merchant Category 
Code (MCQ or specific merchant ID. This gives the merchant the ability to target 
s that have transacted at their location, competitors en masse, or 



complimentary MCCs. For example, a boating merchant can target consumers that 
have made purchases at boating merchants, boating service stations, or sporting goods 
stoics. The merchant can further focus the targeting of historic purchase activity by 
g a specific number of prior purchases and/or a minimum dollar amount spent 
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n also define a minimum or maximuin purchase anKranl, as wdl as a 



« the targeted merchants during . specific period. Other targeting cnteri, liable to 
the merchant include airline tn»vel information, months since last move, credit Hnut, 
credit instrument available funds, consumer state, and consumer five digit np code. 
Merchants or meiracquuers can sut>mit^ 

number of cardholders who would qualify for a particular proposed discount offer. 

Merchants can thereby fme tune their target criteria to reach an audience of the desired 

size and level of interest 

Merchants can define the discount amount of the value propositions to be a 
percentage of the total purchase or aflat dollar amount They can also define whether 
the value proposition is a one time offer or unlimited for a specified promotion period. 
Ifthevaluepropositi^ 

discount percentage or amount between the first and subsequent purchases. The 
merchant canal 
maximum d 

; Once the target criteria have been defined, an automated process n 

value propositions against the consumer data base supplied by the participating issuers 
to find eUgible consumers. Each consumer will receive multiple value propositions 
from differ me«h^ The limit on the number of value propositions provided to 
each consumer each month is defined by a parameter in the automated system. If the 

j corasuu^iscHga^ 

value propositions. In the preferred embodiment, value oppositions an, prioritized 

basedoo the total tonsacu^ 

proxy for oetermming those value proposition mosthkery 

to and find valuable. The formula used to calculate expected total transaction 
■5 ' dollarvolumedepeadsonanun^offeaturesoftheoffer. TWs prioritization 
formula will be updated automatically as data on actual offers is received. 

This prioritization of merchant offers may be altered by the cardholder's 
issumgfinandal institution. Issuing institutions may automatically or manually either 
exclude or preference particularoffcrs for r^cular cardholders. For instance, if an 
" - * g bank is also participating in a co-branding program with an oil company, it 
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may want to, or be contractually required to , exclude its co-branded cardholders from 
receivingdisco^toffersfrom Or, a bai* may want to use 

additional demographic informatioo on its cardholders to override or further refine the 
defeuh^oritizationofof&rsto certain oral! of its cardholders in an attempt to 

5 further maximize card usage and customer satisfaction (and obtain a competitive 
advantage over other issuers). 

Through an automated process, consumers receive notification ofthe value 
propositions available to them along with the pertinent i D formatiom discount amount, 
minimum or maximum purchase (if applicable), maximum discount amount (if 

10 applicable), and expiration date. The redemption of the value propositions is 

providef|Ltabltshment No coupon is provided or required The purchase 
tiamjacticmispiocessedthrougfe 

where the discount is applied. The original purchase transaction akmg with the 
15 dtsWHmttraiKac^ 

processed and sin^n^ The purchase and the 

discount transaction are also provided on the merchant's next statement by its 
ac^urrmginstituuor. After tr* offer r*riod has expi^ 
receive reports surmnarizmg the response rate, i.e. success of their offers. 
20 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagram ofthe major process flows ofthe invention; 
Fig. U is a diagram of the Merchant Management process; 
Fig.l .2 i s a diagram of the Offer Devetopmentprwxss; 
Fig. 1-3 is a diagram ofthe Offer Management process; 
25 pig. 1.4 is a diagram ofthe Issuer and Card Group Management process; 

Fig- 1-5 is adiagram ofthe CardholderAlcketTape processing; 
Fig- 1.6 is a diagram of the Cardholder Extract process; 
Fig. 1.7 is adiagram of the Offer Assignment process;^ 
Fig, 1.8 is a diagram ofthe Offer Delivery process; 
30 Fig. 1.9 is a diagram of the Offer Fulfillment process; 



Fig. 2 is a diagram of the process flow involved in checking for cardholder 
participation. 

DETAILED DESCRIPTION 
Fig. 1 shows an overview of the major process flows of the Program. Block 1 
represents Merchant Management which entails the collection and maintenance of 
information on all participating merchant outlets required for the implementation of 
thePrograrn. This information is mainlined in the Merchant Data Store, a collection 
of files which includes the Merchant Table, Merchant Financial History Table, 
Merchant Category Code Table and the Merchant Qualification Criteria. Blockl is 
expanded and farther explained in Fig. 1.1. Block 4 represents Issuer and Card Group 
Management which entails the collection and maintenance of data on the issuers and 
their cardholders who may be subdivided by the issuer into up to 36 separate card 
groups. Block4feexpajid^iuid^ 

.... «i * -t r. •••urininvrina isSUCTS* MaStCT 



process ot Extracting paiuvipou"© - — — r 

5 Cardholder files. This block is expanded and further explained in Fig. 1.6. BlockS 
represents Cardholder and Ticket Tape Processing, i.e., the means by which the 
transaction histories of participating cardholders are updated and incorporated in the 
Program Matching File for use in the Cardholder Offer Assignment process. Blocks 
is expanded and further explained in Fig. 1 .5. Block2 represents the Offer 

•0 Development process wbereby merchants and their acquirers formulate and test 
discourtfofimarrfdev^ 

is expanded and further explained in Fig. 1 .2. Bl<^ 3 represents the Offer 
Management processes v/hich includes the review of offers by issuers, their 
prioritization into value tiers, and the final release of offers for use in the matching 
25 process. BlockS is expa^ed ami fu^ Block 7 represents 

t^C^Assigr^entprocess. This include me rr*t^ 
their distribution to cardholders who qualify for more than the maximum number of 
offers, and the "fair share" allocation of oversubscribed offers. Block 7 is expanded 
and^plair^furtherinFig.1.7. Blc^ 8 represents tne pr^ 
30 v d^<x*^*to^<foto' M ^*d&- Block 8 is expanded 
and «plamed further in Fig. 1.8. Block 9 represents the Otter Fulfillment process in 
which offers completed by qualifying cardholders are automaticaUy detected and the 



further explained io Fig. 1 .9. 

Fig. U details the Merchant Management process through which all of the 
data on all participating merchants required for implementation ofthePiogtam is 
5 collected and maintained in the Merchant Data Store. The collected data is necessary 
for the offer prioritization process and the issuer preference and exclusion processes 
which will be discussed in more detail in the context of the Offer Argument process 

detailed in Fig- 1.7. 

Every week in step 1.1.7 a file is created fiom the Merchant Master File, 
10 l.U,list^ Tneresukisthe Merchants File 1.1.6. The 

Merchants File is then pre-processed in the Merchant Load step 1 . i .5, wherein each 
merchant record is supplemented with an Area of Dominant Influence (ADI) which is 
assign^ basedontter^ The xcsultine supplemented 

records are stored in the Merchant Table 1 . 1.4. 
15 To keep closer tabs on Merchants whose status has changed (e^, has suffered 

financial problems or closed outlets) a Merchant Update File 1 . 1 -2 is sent daily from 
the merchant pmcessor. This file contains all the changes which were made to the 
merchant's record. This information is added to the Meltable (1.1. 4) through 
me Merchant Up<U^step(U3)W 
20 merehantevdUbenpdatedto 

daily Merchant Update is primarily to track particularly time critical information, e.g. 
the discovery of a fraudulent merchant. 

The monthly sales and traixsactkrair^ 
extracted from the MerchantFmar^ 
25 thesystemmtheformof^ Records from 

tnisfflearea^inonflir/mtte 

Merchant Financial History Table (1.1.13) in the Merchant Data Store. The table 
contains up to 13 months of financial ^transaction summary information for euch 
merchant outlet. Durmg the Klerch^ 
30 data is deleted fiom the table. 

Visa and MasterCard Merchant Category Code (MCQ information on 
partidpanngmerehauts is storedtathe 
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by the merchant processor. This file is used to update the records in the MCC Table 
(1.1.18) in the Merchant Data Store The records intheMCCTable also contain 
manually entered MCC Cluster data that is maintained during the update process. 
New MCCs may be added during the update but old MCC records are not deleted. 

To qualify for participation in the program, merchants must satisfy the 
Merchant Qualification ^ 
Merchants may be disqualified from parficipation based on their MCC, Merchant ID, 
Annual Dollar Volume, Annual Transaction Volume, or Acquiring Bank. Whenever 
troonnation is changed in the Merchant Table (1.1.4), the merchants must be 
requalified by execution of me Merch^ 

requires comparison of the Merchant data in the Merchant Table (1.1.4) with the 
Merchant Qualification Criteria (1.1.10). 

The Offer Development process is detailed in Fig. 1 2. In step (1 .2.7) the 
Dcalmaker, working with the Merchant, creates a new proposed promotion. A 
promotioa will contain one or more offers to be delivered to cardholders. The 
promotion contains the basic information common to the related offers. The 
promotion information required of the dealmakcr or merchant includes: Name (a short 
name for the promotion, e.g., Toys V Us National Sprmg 96 Sales Campaign"); 
Begin Date (Month and Year-all promotions begin on the first of the month); End 
Date (Month and Year-promotions always end on the last day of the month); 
Description (a multi-line detailed description of the promotion). 

Deataakosandmereban^ 
suit the merchant's need and goals. Offttdiscourrtscari be either^ 
doUaxamount. Dwcountsc^app^ 
i be phased with different discounts between the initial and subsequent purchases. 
Discounts can be limited by reaming a minimum purchase or maximum discount per 
cardholder or maximum audience size, i.e., by capping the number of cardholders who 
can receive the offer. 

The ability of merchants to target a specific populatica of cardholders based 
) on purchasing behavior and account characteristics is an important element of the 
Program. Merchants can select targeting criteria based on the following cardholder 
data: state of residence; AD1 (Area of Dominant Influence, a television marketing 
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that defines metropolitan areas); Z1P3 (first three digits of the cardholders zip 
code); months since last move; credit limit; open to buy (credit limit-current balance); 
purchase history and travel information. 

Purchase history is a particularly important targeting criteria. The Program 
maintains a purchase history for each of the p^cipating issuer's caitihoiders in 
which thenumber and dollar volume of a cardholder's tran^ 
intotteeetyr^sofqiiarterly^kets"; by mercliant, MCC (Merchant Category 
Code), and overall. Merchants may also target cardholders based on travel data, i.e., 
the number of trips to a particular destination airport per quarter (where plane tickets 
charged on the consumers participating bankcard). Finally, merchants can target 



of responses to offers by quarter, cither overall, by MCC or by me!^ All 

d in calendar quarter buckets. The 



Program maintains five quarters of data, the current and the last four complete. For 
i, cardholder activity can be sununarized over any combination of 



quarters which need not be consecutive. 

When targeting a cardholder population, merchants can use any or all of the 
characteristics Usted above ai«l logical W and "of operators can be used to 
combine criteria. fo<1.2a)Dea!m^ 

can be executed nightly to determine the number of cardholders which meet me 
raer char^ target criteria. Batch^es are entered through tte Offer Target Qu^ 
Screen (1 ^) and are stor^ in the Batch Queries File (1.2.3). The Batch Queries arc 
executed imd matched agah^ (1.2.18) instep 1X4. Batch 

query results are stored in 1 .2.5 and are supplied to me Deahnaker or Merchant on 

Query Status Screen (1.2.6). 

The finalized offers are then added to the Offers Table (1.2.8) and assigned to 
one of three value tiers based on a value score proportional to the expected transaction 
dollar volume, a measure of the expected value of the offer to cardholders. The value 
score is calculated as a function of 6 parameters: * 

(1) Discount percentage. For offers which have "stepped" discounts, the 
mgherdiscoumtevelisused. For offers which a dollar off rather than a percent off, 
the dollar amount is converted to a percent by dividing it by the minimum purchase if 
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there is one, or the average merchant ticket amount if the offer has no minimum 
purchase. 

(2) Targeting Score. This factor is intended to reflect how targeted the 
offer is and can take one of three discrete values. 
5 (3) Average Ticket. This is the merchants average ticket over the 

preceding twelve months. 

(4) Duration Score. This factor is intended to reflect the number of times a 
cardholder can act on an offer. Offers in which only the first purchase is discounted 
are given a 1. Offers in which subsequent purchases are discounted a lesser amount 

10 are given a 2. and offers in which all purchases are discounted the same amount are 
given a 3. 

(5) Industry Volume Score. This parameter is used to take into account 
the transaction level of the MCC. The Score can be either 1, 2 or 3 depending on the 
merchants MCC. 

15 (6) Minimum Purchase Required. Offers which require a minimum 

purchase receive a 1 and offers which do not receive & 2. 

The Value Score is currently calculated as a linear function of these 

parameters (except lO/SQRT(Avg. Ticket) is used instead of Average Ticket). The 

seven constants in the formula are calculated fay least squares linear regression using 
20 total transaction dollar volume data as it becomes available. Other more complicated 

predicting formulas may be used and are under examination including neural 

networks. 

Offers are placed in one of the three value tiers based on their value score. 
The minimum value score for each tier is stored in a table and can be updated as 
25 needed to provide for a more even distribution of offers among the tiers. After the 
value tier assignment is made it is displayed on-line for the deahnaker or merchant to 
review. 

In step (1 .2.9) the deahnaker creates an offer graphic to be used as an overlay 
on the receiving cardholders bankcard statement sent Dealniskers/ Merchants can 
30 select a logo from the Program standard library. If the deahnaker wishes to use a logo 
that is not in the library, he can request a custom logo on-line. The custom logo 
request will be routed to Program Headquarters. The deal maker then forwards the 



artwork and a fee. After Program Headquarters loads the new logo into the library, 
thededmakerwM AHoffer 
overlays are required to follow the same general approved format. The Offer 
Management system will generate all overlays using the data elements selected by the 
dealmaker. Each month these files are sent to the offer delivery system for loading 
into the production library. 

In step (1 .2.11) the Dealmaker generates the contra^ wMch must be executed 
by the merchant and its acquirer before a merchant offer can be accepted in the 
Program. The contracts are then forwarded to the necessary parties. A participating 
merchant must have an Executed Offer Addendum Agreement for each Program offer 
they wish to make. Every offer maintained in the Program "deal warehouse" must 
have an active and mutually executed addendum. Once an offer addendum has been 
signed by the merchant and Acquirer, it is maUed to me Program Headquarters for 

approval and storage. 

In step (1-2-16) the program administrator reviews the offers and verifies that: 
the copy and logo are in sync; the logo and copy meet technical standards (overlay 
dimensions, font, excessive use of black toner, 240 dot per inch (dpi) resolution 
quality graphics)^ offer meets the substantive staiwlards required by the program; 
the offer copy and overlay match the description in the contract addendum; the offer 
text has no typographical errors and accurately conveys the information on the 
merchant overlay and Offer Addendum; an executed Master Contract with the 
Merchant and Acquirer is on -file and active; the offer meets any pricing standards 
required by the program; the Merchant' s current status is favorable; and me Merchant 
passes all Program risk controls. If the offer fails one of the above test, it is rejected 
i and sent back to the dealmaker to be brought into compliance. Otherwise, a Program 
representative will sign the Offer Addendum and officially release the Merchant's 
offerfs) into the "deal warehouse" for matching. 

Fig. 13 details the Offer Management process. In step (13.1) Issuers arc able 
to review each of the offers in the Card Group Offers Table (1.3.14) which contains 
0 the specific offers that will be delivered to the cardholders in each of the issuers card 
groups. Issuers can review the effect that their preferences and exclusions had on the 
current month' s offers and during the review process can manually block or 
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preference specific card groups from receiving particular offers using the Offer 
Warehouse screen. 

If the merchant offer information is complete, merchant offers which are not 
blocked are locked in and released for the matching process in step (U.5). Offers for 
5 which the merchant information is not finalized arc removed. 

During step 1 .3.8 Generate Merchant Offers, Merchant's outlet entitlement 
criteria is applied to all of a merchants outlets. Those outlets which meet the criteria 
areeligfcletoparti^ 

as a new record. The outlet entitlement criteria currently available for use by 
10 merchantearel)Ouaet#,2)C^ 

merchants opens any additional qualifying outlets during the promotion run, those 
outlets will be automatically i&aitified during 

(1 .1 .3), added to the participating outlets Ust, and sent on the dairy Merchant Offers 

ffle (1.3.9) to the merchant processor for oufiet entitlement 
15 In step (! 3. 12) the locked in merchant overlays in the Overlay library are 

delivered in the Overlay Files (13.13), 

Fig. 1.4 details Issuer and Card Group Management through which cardholder 

information and cardholder segmentation by the issuers is received into the program. 

This information includes the Issuers' Processor Client number which is used to 
20 identify participating cardholders and tickets during the Cardholder Extraction 

process. Issuers also provide the definitions of one or more Card Groups into which 

their participating cardholders are segmented. The Card Group infonnatkm may be 

provided eitoer on me Issuer Setu^^^ 

between the Issuer and Program Headquarters (not show). The received information 
25 is written and stored in the Issuer Table (1 .4.6) in the Issuer Data Store. Additional or 

modified information on either new or existing issuers can be entered in the Issuer 

Table (1.4-6) through the Add or Modify Issuer Irdortnation process (1.4.2). 

Issuers can prevent any of their cardholders from receiving particular Offers by 

defining issuer-level merchant exclusions which can be entered into the Issuer Table 
30 (1.4.6) using the Issuer Preference Maintenance Screen (1.4.5). Issuers can define 

exclusions based on Program Merchant ID; Merchant MCC or MCC Cluster (or all 
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offers from a particular MCC or MCC Cluster except those from particular 
enumerated merchants); or Merchant Type (i.e„ National/Regional or Local). 

The Card Group definitions are entered in the Card Group Table (1.4.8) in the 
Issuer Data Store, through the Card Group Maintenance Screen (1A7). The Card 

5 Group Table (1 .4.8) includes the text description included on the cardholders 
statements to identity Program credit and return transactions. This description is 
placed in the same field in the cardholders statement in which the merchant's name 
appears in the record of the associated sale transaction. One descriptor will be 
provided for each Issuer Card Group. Though, the Issuer may elect to provide the 

10 same descriptor for all Issuer/Card Groups. These credit and return transaction 

descriptors are limited to 22 characters to ensure that the same descriptor can be used 
for both Visa and MasterCard transactions. 

Issuers can separately affect the offers received by the members of different 
Card Groups by providing merchant exclusion and r>rkmtization parameters for each 

15 Card Group. This information is entered through the Card Group Preference 
Maintenance Screen (1.4.7) and is stored in the Card Group Preferences Table 
(1 Al 1). Issuers can include, exclude or prioritize offers for each Card Group based 
on the following merchant parameters, Program Merchant ID Number; Merchant 
Category Code, Merchant Type (^onal/Regional, or Local). Using this automated 

20 process, issuers can largely avoid manually reviewing and ranking offers within each 
card group. Use of the parameters and Card Groups provides an automated and 
manageable process for issuers to deal with the large number of offers and potential 
contractual conflicts (e.g., Affinity or Co-brand programs) while at the same time 
allowing for differentiation (and competition) from other issuers. A history of all 

25 changes made to the ranking and selection rules is maintained for audit and control 
purposes. 

The Issuer and Card Group Description Table is stored at the merchant 
processor and provides the credit and return transaction descriptor text to be used for 
each member financial institution. This text is placed in the credit and return 
30 transactions and is printed on the cardholders statement Each issuer will have 
different text, thereby allowing them to distinguish and "brand" their card groups. 
Each month, the processor loads the new Issuer/Card Group Descriptions File (1 .4.21 ) 
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whereby the records in the Issuer and CardGroup Descriptions File (1.4,20) are added 
to the Table. 

The Cardholder and Ticket Tape Processing steps to create and update the 
Program Match File {1 .2.18) are detailed in Fig. 1 .5. In Step (1.5-6), the processor, 
5 using the Issuer Card Groups, extracts the tickets for each participating Program 
issuer and writes them to an extraction file (1.5.2). This file will, at the end of the 
process, contain all of the tickets for the participating issuers (not just the tickets for 
participating cardholders). This extraction process takes one of two forms depending 
on whether or not the Issuer is new to the program. When a new issuer joins the 
10 program a New Issuer One-Time Load is required in which all tickets for the past 122 
days are extracted from the processor on-line database. For issuers who are already 
participating in the program, only the past day's tickets are extracted. 

The resulting Daily Tickets File (1-5.2) is preprocessed to add additional 
fields. The resultant records are added to the previous days tickets ( 1.5.2) to create a 
1 5 new Ticket Summary File (1 .5.5). This process uses merchant and MCC information 
found in the Merchant Xref Table (1.5.9) and the MCC Xref Table (1.1.12) to provide 
the cross-reference numbers for MCCs and merchants. The Ticket Summary File 
summarizes cardholder purchase activity by merchant, MCC, MCC Cluster, and 
Airline Destination City. The file stores transaction and dollar amount totals for all 
20 sales and returns (not just those under the Program) for each of the last five quarters 
(four quarters plus the current quarter). This update process is run daily. 

The Program Cardholders File (1.5.8) is created in step (1.5.15) which is 
repeated monthly. The Extract Program Cardholders File ( 1 .5.1 5) which was created 
in the Cardholder Extraction Process is received, formatted and preprocessed to add 
25 additional fields. Additional data elements are then added to the records including the 
cardholders' ADI, found in the Geographic Data File Table (1.5.1). Cardholder 
records with a 'Z' in the Card Group field (i.e., records for cardholders who have been 
excluded from participating in the program by their issuer) are not included in the 
Program Cardholders File (1.5.15). 
30 Monthly Match File Creation (1.5.16) is run where a participating cardholder's 

purchase information, stored on 1 .5.5, is merged with the cardholder information, 
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stored on 1 .5.8, to create the Program Match File (1 .2.18) which is used during 
Cardbolder Offer Assignment (1 .7.1). 

During the daily ticket processing in step (1 .5.3), a copy of each Program 
licketandrctumis:*^^ TOs table is used to 

monitor the offers, and create management and member reports. S imilarly a record of 
each non-program return transaction, regardless of issuer is saved in the Returns File 
0.5.12). Only return records from the last 90 days are maintained in this file, older 
records are purged. The purpose of this file is to allow for easy monitoring of 
potential fraudulent return activity. 

In Step 1 .5.14 the Offers Table (1.2.8) and Card Group Offer Table is updated 
daily with information from the Detail Response File (1.5.1 1) in order to allow 
tracking of offer perfonnance on a daily basis. Offer response data added to the 
Offers Table (1.2.8) through this process includes: Number of Purchases (add day's 
transact ions to current total); Gross PurcbjtseAmomt(addoay'sUUetamomitsto 
current total ticket amount) as well as Number of Returns and Gross Return Amount 
Fig. 1 .6 details the Cardholder Extraction process. Through this process, the 
Master File of participating cardholders and their card group assignments is updated 
monthly. In step (1.6.1) the issuers in the Program define a Card Group for each of 
men- participating cardholders. As described above. Card Groups are used to segment 
the issuer's cardholders into manageable categories for purposes of ranking Program 
offers and specifying custom selection criteria. The grouping characteristics are 
determined by the issuer who codes each cardholder account with a one a one- 
character Card Group identifier via a "non-monetary" electronic transaction. 
Correspondingly, an Offer Management System screen will setup the same Card 
25 Group identifiers and issuer^hosen descriptions so that the card groups can be used in 
both screen displays and reports to categorize, summarize, and manage sets of 
cardholders. 

Each issuer can define as many as 36 different card groups each of which is 
represented by a single character '0* through '9' and *A* through *Z' . A value of Z in 
30 fte Card Group field on a cardto^ 

that the cardholder has not been selected to participate in the Program. Participating 
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stored on 1-5.8, to create the Program Match File (1 .2.18) which is used during 
Cardholder Offer Assignment (1.7.1). 

During the daily ticket processing in step (1 .5.3), a copy of each Program 
ticket and return is saved in the Detail Response File (1 .5.1 1 ). Tins table is used to 

5 monitor the offers, and create management and member reports. Similarly a record of 
each non-program return transaction, regardless of issuer is saved in the Returns File 
(1.5.12). Only return records from the last 90 days are maintained in this file, older 
records are purged. The purpose of this file is to allow for easy monitoring of 
potential fraudulent return activity. 

10 In Step U.14 the Offers Table (1X8) and Card Group Offer Table is updated 

daily with hifoirnation fawn the Detail I^nse Fife {1 .5.11) in order to aHow 
tracking of offer performance on a daily basis. Offer response data added to the 
Offers Table (1 .2.8) through this process includes: Number of Purchases (add day's 
transactions to current total); Gross Purchase Amount (add day's ticket amounts to 

15 current total ticket amount) as well as Number of Returns and Gross Return Amount 
Fig. 1.6detaiktheCardlK>lderExtractkmpioc^ Though this process, the 
Master File of participating cardholders and their card group assignments is updated 
monthly. In step (1.6.1) the issuers in the Program define a Card Group for each of 
their participadng cardholders. As described above, Card Groups are used to segment 

20 the issuer's cardholders into manageable categories tor purposes of ranking Program 
offers and spwirymg custom selection criteria. The grouping characteristics are 
detcrmmedby me issuer^ 

character Card Group identifier via a "non-monetary" dectronic transaction. 
Conesrwndingly, an Offer Management System screen will setup the same Card 
25 Group identifiers and issuer-chosen descriptions so that the card groups can be used in 
both screen displays and reports to categorize, summarize, and manage sets of 
cardholders. 

Each issuer can define as many as 36 different card groups each of which is 
represented by a single character '0* through *9' and *A* through 'Z*. A value of Z in 
30 the Card Group field on a cardholder's record in the Cardholder Master File means 
that the cardholder has not been selected to participate in the Program. Participating 
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cardholders are those who have not opted-out and whose issuing bank has selected 
them for participation (by not assigning them to card group Z). 

The non-monetary electronic transactions (1.6.4) through vfcich the issuer 
sends the processor the cardholders Card Group can be submitted by the issuer at any 
time, are processed as they are received, and are used to update the Cardholder Master 
File ( 1 .6.5). The updated information will not be reflected in the Program Master 
Database, however, until the next monthly processing cycle. 

The Issuer Definition File (1.6.8) which contains a unique client number for 
each participating issuer is received into the system each month and used to update the 
Issuer Control file which is matched against the Cardholder Master File in the final 
Cardholder Extraction in which the records of all of the cardholders for each of the 
participating issuers arc copied from the Cardholder Master File to the Extracted 
Program Cardholder File. 

Fig. 1.7 details the Offer Assignment process. After offers have been received 
in the Offer Management System and assigned a value tier, out before the offer 
warehouse is opened for inatching, each Card Group's preference criteria are applied 
to the available offers. This results in six value tiers of offers Al, A, Bl, B, CI and C 
for each card group where the"!" value tiers meet the preference criteria specified by 
the issuer for that card group. 

The first step in assigning offers to a cardholder is to determine the Card 
Group to which the Cardholder belongs. The matching engine then uses the Match 
File (1X18) and the Card Group Offers Table (13.14) assign offers from that Card 
Orc^ Al tieruntil aprtx^inimber of as^ 

engine docs not find 10 offers in tier Al, it either goes to tier A or Bi depending on 
whether the issuer has chosen "Value" or "Preference" matching. If an issuer chooses 
"Value Matching" the tiers are ranked Al, A, Bl, B, Cl, C. If the issuer chooses 
"Preference Matching", the tiers are ranked Al, Bl , CI, A, B, C. Once a cardholder 
is assigned ten offers the engine moves on to the next cardholder. During this first 
pass, a counter is kept of the number of cardholders assigned an offer. 

After all cardholders have been assigned ten offers, a second "fair share" 
assignment pass is made. Two critical factors create the need for a second "fair share" 
offer assignment pass. First, cardholders are read in sequential order (i.e. grouped by 



Issuer). Second, some merchant offers are capped (i.e., are sent to a limited number 
ofcardholders). ww.tttop««^<ttol)«»rftelil^ 
never receive capped offers. During the "fair share- run, offers which are 
"oversubscribed 1 ' are reallocated evenly throughout the list of cardholders. E.g., if the 
offer was over subscribed by a factor of 10 every tenth cardholder who received it in 
the first pass gets it in the second pass. At the end of the second assignment pass, 
caidholderskeep the first six offers still available to them from the ten assigned 
during the first pass. 

In step (1.7.5), after the assignment process is completed, the Selected Offers 
Files are created. For each Card Group, the total number of cardholders assigned to 
each merchant offer is determined and stored in the Issuer/Card Group Offers Tables. 
The Assigned Offers Summary File (1.73) is created containing one record for each 
merchant offer delivered to one or more cardholders in any Card Group, and is used to 
in step (1.7.4) to verify that each merchant offer in the file has a wrresrKHiding offer 
overlay. The absence of an overlay is communicated to the Program Headquarters so 
that the offer overlay can be transmitted for inclusion in the overlay library 

Fig. 1.8 details the offer delivery system. In step 1.M0, the Cardholder 
Selected Offers File (1 .7.5) is received into the statementmg system each month. This 
file contains the cardholder account and the merchant offers that the cardholder will 
bo delivered. The Cardholder Selected Offers File is then matched with the Overlay 
Library (1.3.13) which contains each of the possible offer overlays forme current 
month. Each offer overlay in the Overlay Library is coded to match a unique 



file contains one or more o 

In step (1 .8.2) the Cardholder Statements vrith me apprc^mate offer overlays 
are printed. Before the offers are printed, however, the Issuer Policy Information 
must be matched with the statementing accounts in the Cardholder Statement Data file 
(1.8.1) from the nightly cycle to determine which cardholders getstatemented 
Because the cardholder characteristics may have changed between the time that the 
cardholder was identified as eligible for certain offers and the time the statement is 
actually printed, the system performs edits against the cardholder account, to confirm 
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that the cardholder has not opted-out or otherwise become ineligible for the program 
and may have to be excluded from receiving an offer page. 

After the statements are printed, the system creates a Cardholder Statement 
Positive File (1.8.3) which contains a record for each cardholder who was delivered a 
5 Program statement page. Similarly, a Cardholder Statement Negative File (1.8.7) is 
created which contains a record for each cardholder who did not receive a Program 
statement and a reason code indicating why no statement was sent In step (1.8.8) the 
Cardholder Statement Positive flic (1.8.3) is used to update a variable within the 
Offers Table (1.2.8) which tracks the running totdofthe number of cardholder 
10 which have been delivered an offer. 

The Cardholder Statement Positive FUe(I.83) is also delivered daUy to me 
two subsystems which process the cardholder and merchant transactions. Instep 
(1.8.4), the cardholder processor adds the offers contained in the File to its own 
Cardholder Offers Table which contains all active offers and expired offers for a 
15 period of six months beyond the expiration date Similarly, in step (1 .8.5) the 
Cardholder Statement Positive File is used to update the merchant processor's 
Cardholder Offers file which contains an up-to-date account of all offers that have 
been dehvered to a cardholder m the past 180 days. 

Fig. 1.9 details the OfierFiilfiUment process. In Step (1.9.1% Merchant 
20 Entitlement to participate in the Program for the month is set The Merchant Offers 
File ( 1 .3.9) which contains information on participating merchants is transmitted to 
the Merchant Processor where the uulrcniaton from the ffi^^ 
meicharrt accounts troces^ 

makes a sale to a qualifying cardholder who has received the merchants discount 
25 offer, the cardholder will receive the discount as an automatic credit without any 
further action (beyond normal credit card sales processing) on behalf of either the 
merchant or the cardholder. In Step (1 .9.3) the merchant transmits the sales draft to 
the processor as it would any other credit card sale. The processor then determines 
whether the card holder is entitled to a credit on me transactiori by comparing the 
30 transaction information from the draft with the Merchant Entitlement information in 
the ( 1 .9.2) file and the Cardholders Offers Table (1.9.6). The logic of this 
determmation process is shown explicitly in Fig. 2. A cardholder is eligible for a 
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Program credit if: (I) they purchased goods or services from a merchant who is 
currently participating in the Program; (2) they were designated as being eligible for a 
merchant ofier (Le., they were sent an offer along with their monthly bankcard 
statement); (3) they met the requirements of the specific offer being run by the 
merchant (e.g.. have made the minimum purchase); and (4) the sale is made during the 
offer period 

The Program credit is then generated in step (1 .9.7). The amount of the credit 
depends on the details of the offer (e.g., discount percentage and or amount) which are 
contained in the Merchant Offer Table. For processing through the interchange, the 
credit transaction is assigned (he same transaction number as its associated purchase 
transaction. Special product codes are create which corresponding to either Visa or 
MasterCard Program credits. A description of the credit transaction is taken from the 
Issuer/Card Group Descriptor Table which is indexed by issuer ID and Issuer Card 
Group, These two values arc retrieved from the Cardholder Offers Table and used as 
the unique key to look up the appropriate record in the Issuer/ Card Group Descriptor 
Table, the credit transaction description text is retrieved from the record and 
incorporated into Ac available text space on the credit transaction. The maximum text 
Iwgth is 22 characters so thM 



30 



If the draft submitted in step (1 .93) is a purchase reversal (a return of 
merchandise) the merchant processor checks the Merchant Processor USAVE 
Transaction Database to I) determine if the caidholder had previously transacted on 
an offer from the rnerchant, and 2) if the purchase amount of me offer matches the 
returned amount on the purchase reversal . If both conditions are true, a debit is 
generated, in the step (1.9.7), for the amount as the previously issued credit This 
permits the merchant to recoup the credit they had iss ued on the on gind transaction . 

In step (1.9.10) the processor sends the transaction through the Interchange. In 
step (1.9.12) the issuer's processor accepts the interchange transaction, recognizes and 
flags it as a Program transactiott and updates the Ticket Database (1 .9.14) to include 
the transaction. This information is passed back and updates the ticket file and the 
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This detailed description is of an embodiment of the invention in a credit card 
processing environment. Upon reviewing the disclosure herein, embodiments of the 
invention in any other payment transaction processing system, including checks, debit 
cards, private label cards, and on-line electronic payment systems will be obvious to 

5 those of ordinary skill in the art Similarly, though the communications and 

statements in the embodiment described in the detailed description take the form of 
printed mailings, it would be equally obvious to one of ordinary skill in the art that 
they could be replaced with electronic visual or audio communications. Such 
variations or modifications are intended to be encompassed within the scope of any 

10 claims to pat^ protection issuing upon this invention. 
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1 l. A method for operating a general purpose digital computer having data 

2 storage memory foratarget^^^ 

3 of: 

4 (a) datastoriitginfonnatrononiiKUvidualcoiisu^ 

5 one or more payment systems institutions each of which supplies payment means to a 

6 subset of said consumers, said consumer information includes the targeted 

7 characteristics of said individual consumers; 

g (b) data storing in a computer memory information on merchant 

9 discount offers obtained from one or more acquiring financial institutioris each of 

10 wmchsemccsastitee^ 

11 includes the discount amount, transact requirements and consumer target criteria; 

12 (c) identifying qualifying consumers for particular merchant 

13 dis^unt offers by computer matchm^ 
14 

15 «*> 

16 tequirementsof the discount offers for which the consumers qualify; and 

17 (c) automatically applying to the quaUfying consumers' payment 
,8 systems accounts the d^Sa^u^offers for which the qualifying consumers 
19 meet the transaction requiremeots. 

! 2 . Tteme&odofclamilwfa^ r 

2 consumers is supplied by a plurality of payment systems ir^rttmons.treak 

! 3. The method of claim I wherein wetafbnnation on merchant discount 

2 offetsfaobtamedfomaplur^ 



i 



4. The method of claim 2 wherein the information on merchant discount 



2 offers fe obtained fom a plurality of acquiring financial institutions. 
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1 5. The method of claim 1 farther comprising the step of automatically 

2 notifying consumers of said merchant discount offers for which they qualify. 

1 6. The method of claim 5 wherein the consumers are notified of only a 

2 subset ofthe merchant discount offers for which they qualify. 

1 7. The method of claim 6 wherein the subset of merchant discount offers 

2 for which the consumers qualify and of which they are notified is determined based on 

3 a prioritization of discount offers using a function of expected transaction volume, 

4 total discount, and total purchase amount, 

t 8. The method of claim 7 wherein said prioritization function is expected 

2 response dollar volume which is calculated based on a plurality of parameters relating 

3 to each of said offers. 

1 9. The method of claim 8 wherein one of said parameters is the offering 

2 merchant's past transaction dollar volume. 

1 10. The method of claim 8 wherein one of said parameters is the offering 

2 merchant's industry's past traiisae^ 



U . The method of claim 8 wherein one of said parameters is the discount 



1 12, The method of claim 8 wherein one of said parameters is the ratio of 

2 the discount amount of said offer to the average purchase amount at the offering 

3 merchant. 

! 13. The method of claim 8 wherein one of said parameters is the ratio of 

2 the discount amount to the minimum purchase requirement of said offer. 
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t h. Thcn^thodofdaimSvvheieinoneofsaidparametersistheTatioof 

2 themmimumpurcha*^ 

3 the offering merchant 

1 15. The method of claim 8 wherein one of said parameters is the level of 

2 



j 16 . The method of claim 8 wherein one of said parameters is the average 

2 purchase amount at said offering merchant. 

! 17. TheinethodofclaimSw^ 

2 limitations placed on the discounts available under said offer. 

j 18 . The method of claim 8 wherein one of said parameters is the number of 

2 discounted purchases which can be made under said offer. 

! 19. The method of claim 8 comprising the further step of using a computer 

2 and the infonnation on actual transaction dollar volumes resulting from merchant 

3 disc^uirt offers to update me function used tocd^ 

4 volume to make it a more accurate predictor of actual transaction dollar volume. 

! 20. The method of claim 1, wherein the consumer's payment systems 

2 financial institution can affect the merchant discount offers received by the consumer. 

\ 21 The memod of claims 1 comprising the f^ 

2 fdterinB the merchant discount offers for which a consumer otherwise qualifies based 

3 oh filter criteria provided by the consumer's payment systems institution. 

! 22. Tbemethodof claim21 vAeremsaidfilter criteria irKJudes at least oi^ 

2 of demographic characteristics of the consumer, the type of credit instrument, 

3 cfcKacteristicstf^ 
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1 14. The method of claim 8 wherein one of said parameters is the ratio of 

2 the minimum purchase requirement of said offer to the average purchase amount at 

3 the offering merchant. 

1 15. The method of claim 8 wherein one of said parameters is the level of 

2 targeting of said offer. 

1 16. The method of claim 8 wherein one of said parameters is the average 

2 purchase amount at said offering merchant. 

1 17. The method of claim 8 wherein one of said parameters is a function of 

2 limitations placed on the discounts available under said offer. 



1 18. The method of claim 8 wherein one of said parameters is the number of 

2 discounted purchases which can be made under said offer. 



1 19. The method of claim 8 comprising the further step of using a computer 

2 and the information on actual transaction dollar volumes rcsnltmg from merchant 



3 



4 volume to make it a more accurate predictor of actual transaction dollar volume. 

1 20- The method of claim 1, wherein the consumer's payment systems 

2 financial institution can affect the merchant discount offers received by the 

1 21. The method of claims 1 comprising the further step of automatically 

2 filtering the merchant discount offers for which a consumer otherwise qualifies based 

3 on filter criteria provided by the consumer's payment systems iristitction. 

1 22. The method of claim 21 wherein said filter criteria includes at least one 

2 of demographic characteristics of the consumer, the type of credit instrument, 

3 characteristics of the offer, and characteristics of the offering merchant 
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1 23. The method of claim 21 or 22 wherein the effect of said automatic 

2 filtering is to prevent particular consumers from receiving particular offers for which 

3 they otherwise qualify. 



24. The method of claim 21 or 22 wherein said automatic filtering affects 
the prioritization of offers for which the consumer qualifies and may thereby cause the 
consumer to receive a different subset of the offers for which he qualifies. 



1 

2 
3 

1 

2 the order in 



25.: < The method of claim 21 or 22 wherein said automatic filtering affects 
which the offers are printed on the consumer's statement. 



1 26. The method of claim 6 comprising the further step of allowing the 

2 consumer's payment systems institution to manually prevent particular consumers 

3 from receiving particular merchant discount offers. 



1 27- The method of claim 6 comprising the further step of allowing the 

2 cor^cr'spayment systems institution to m^ty 

3 and thereby cause the consumer to receive a different subset of offers for which the 



1 28. 



The method of claim I comprising the fertber step of allowing the 



2 consumer's payment systems institution to n 

3 offers are printed on the consumer's 



manually affect the order in which the 



The method of claim 1, comprising the further steps of: 



(a ) automatically deterrmning the number of consumers whose 



I 

3 target characteristics match the target criteria of a proposed merchant discount offer, 

4 and 

5 (b) supplying the merchant with the number of matches so that the 

6 merchant can assess the likely success of the proposed offer. 
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1 30 The method of claim I , comprising the further step of automatically 

2 rep ortingperi^ 

3 merchant's offer. 

1 31. The method of otairo 1 wherein one of sad taigetedchatactcristics is 

2 the consumer's payment transaction history. 

! 32. Themethodof claim t wherein one of said targeted characteristics is 

2 the consumer's prior responses to Program offers. 

j 33. The method of claim I wherein one of said targeted characteristics is 

2 the consumer's zip code. 

t 34. Themethodof claim 1 wherem one of said targeted characteristics is 

2 the consumer's ADI. 

t 35. The method of claim ! therein one of said targeted characteristics is 

2 the consumer's state. 

1 36. Themethodafdai^ 

2 the consumer's spending limit through said payment system. 

, 37 The method of claim 1 wherein one of said targeted characteristics is 

2 the amount the coitsum^ 

! 38. Tte memc>d of claiml v^m one of said targeted ch^ 

2 the number of months since the consumer's last change of residence. 

j 39. The method of claim 1 wherein said targeted c/namcteristics includes 

2 information by the consumer's travel. 



1 40. The 

2 restricted to a limited number of consumers. 
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method of claim I wherein said merchant discount offers may be 



41. The method of claim 1 wherein said merchant discount offers may be 
d to a limited number of consumers and comprising the further step of 
distributing*** restricted offers so as notto discrimmate among parncipating 



4 payment systems institutions. 



! 42. The method of claim 1 comprising the further steps of: 

2 (a) lowing** corner's paym^ 

3 custom indicia; and 

4 (b) automatically displaying said custom indicia in the payment 

5 system institution's communication to the consumer. 



j 43. The method of claim 1 comprising the further steps of: 

2 (a) auowingtheeoiisumer's^ 

3 descriptive text; and 

4 ^ automatically displaying said descriptive text in the payment 

5 system mstituuor,'s communication to the consumer contiguous to said discount 

6 credit 

{ 44. The niethod of claim I wr^emsdd merchant disc^urrt offers can b^ 

2 limited to particular merchant outlets. 



1 45 The method of claim 1 wherein the participating merchants c 

2 the form of said merchant discount offers uclndlng whether said offers (a) involve a 

3 flatori^ercentagedis^^^ 
discount, (d) require minimum purchases, or (e) have a maximum purchase 



46. The method of claim 1 comprising the further steps 



2 00 



allowing merchants* design offer overlays dealing said 



merchant discount offers; and 



4 (b) automatically prirUing said offer overlays oo statements^ to 

5 consumers receiving said offers. 



47 ttemeihcK^^ 
debttngt.mtheoo,^ 
puxchasesm^ichthemen^diseislaterr^ 



, 48 A system for a targeted payment system discount program cornpnsmg: 

2 - (a) means for data storing in a computer memory information on 

3 individual consumers supplied by one or more 

4 which supplies payment means to a si 

5 infon^onoKludestl* 

6 (b) means for data storing in 

7 merchant discount offers obtained from one or more acquiring 

includes the discount amount, transaction requirements - 

as for identifying qualifying consumers for particular 



m ^ascotmtofier S by ^ target criteria 



with the 



9 

10 target criteria; 

11 (•) 
12 

13 — - n^^comr^ consumer transaction wmte 

_ . . «- c tVu- «iT«iimers quality; and 



n navr^sys^accot^ 



* 49. T^e system of claim 48 wherein the intbrmatidn on individual 

2 ^r^e^issuppUcdbyapl^ 
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50. The system of claim 48 wherein the information on merchant discount 
2 offers is obtained from a plurality of acquiring financial institutions. 

1 51. The system of claim 49 wherein the information on merchant discount 

2 offers is obtained from a plurality of acquiring financial institutions. 

1 52. The system of claim 48 wherein the consumer's payment systems 

2 financial institution can affect the merchant discount offers received by the consumer. 

1 53. The system of claim 48 further comprising means for automatically 

2 filtering the merchant discount offers for which a consumer otherwise qualifies based 

3 on filter criteria provided by the consumer's payment systems institution. 

1 54. The system of claim 53 wherein said filter criteria includes at least one 

2 of demographic characteristics of the consumer, the type of credit instrument, 

3 characteristics of the offer, and characteristics of the offering merchant 

1 55. The system of claim 53 or 54 wherein the effect of said automatic 

2 filtering is to prevent particular consumers from receiving particular offers for which 

3 they otherwise qualify. 

1 56. The system of claims 53 or 54 wherein said automatic filtering affects 

2 the prioritization of offers for which the consumer qualifies and may thereby cause the 

3 consumer to receive a different subset of the offers for which he qualifies. 

57. The system of claims 53 or 54 wherein said automatic filtering affects 



1 

2 the order in which the offers are printed on the consumer's 



t 58. The system of claim 48 further comprising means for allowing the 

2 consumers payment systems institution to manually prevent particular consumers 

3 from receiving particular merchant discount offers. 
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The method of claim 48 further comprising means for allowing the 



consumers pnyuiw""/-- — , u 

and thereby cause tocim™*^**^^**"***** 



2 consum^paymentsystemsinsti^ 
3 

4 consumen 

t 60. The method of claim 48 further comprising: 

2 (a) 

4 offer, and 

5 (b ) means for supplying the merchant with the number of n 

6 so that the merchant can assess the likely success of the proposed offer. 

1 61. The system of claim 48 further comprising: 

2 » 

3 to supply custom indicia; and 

4 (b) means for automatically displaying said custom indicia m the 

5 payment system h 



62 . The system of claim 48 further comprising: 
{8 ) n^foratt^thecons^^ 
to supply descriptive text; and 



(b) means for automatically displaying said descriptive text m 

*~said 



5 

6 discount credit 

! 63 . The system of claim 48 further comprising: 

2 (a) means for allowing merchants to design offer overlays 

3 describing said merchant discount offers; and 

4 (b) means for automaticalry printing said offsr overlays on 
s sent to consumers receiving said offers. 
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r 64. The system of claim 48 further comprising the for automatically 

2 debiting from the consumer's payment systems account discounts received on 

3 purchases in which the merchandise is later returned to the merchant for credit. 
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